Add Cards/Files/Definitions metadata to workspace favorites - #5677

Preview deployments

• Host staging preview

• Host production preview

• Boxel UI staging preview

Host Test Results

    1 files      1 suites   2h 45m 1s ⏱️
3 490 tests 3 472 ✅ 12 💤 4 ❌ 2 🔥
3 509 runs  3 489 ✅ 12 💤 6 ❌ 2 🔥

Results for commit 09754f9.

For more details on these errors, see this check.

Realm Server Test Results

    1 files      1 suites   13m 10s ⏱️
2 077 tests 2 076 ✅ 0 💤 1 ❌
2 156 runs  2 155 ✅ 0 💤 1 ❌

Results for commit 09754f9.

For more details on these errors, see this check.

⚠️ Findings 1 and 2 are verified against the source (2 by code-reading, not reproduced); findings 3–11 are not verified at all. The unverified ones come from a code-reading pass — each cites a concrete call site, but nothing was reproduced and no test was written against any of them. Treat them as leads to check, not confirmed defects. The CSS/layout ones especially want a browser rather than a code read.

Worth checking before merge

1. realm_registry.updated_at never moves for source realms — packages/runtime-common/realm.ts:6892

getRegistryTimestamps reads created_at, updated_at FROM realm_registry, but only two code paths ever write realm_registry.updated_at, and both exclude source rows: realm-registry-writes.ts:77 (… DO UPDATE SET last_published_at = …, updated_at = now() WHERE realm_registry.kind = 'published') and realm-registry-backfill.ts:153 (same shape, WHERE … kind = 'bootstrap'). insertSourceRealmInRegistry inserts kind = 'source' with ON CONFLICT (url) DO NOTHING and never sets it, and the schema (1776960113000_create-realm-registry.js:74) has no trigger — just DEFAULT now().

So for every source workspace updated_at === created_at permanently, and the menu footer shows a fixed "Updated 3 months ago" regardless of how much the user writes. The comment at realm.ts:7222 — "updated_at — which moves on any ordinary realm write" — is inaccurate, and since the ETag argument is built on it, that reasoning needs revisiting too.

(The other updated_at = now() writers in the tree — handle-publish-realm.ts:539, create-realm.ts:169, realm-metadata-queries.ts:24,35 — all target realm_metadata, a different table.)

2. measureWorkspaceGrid writes tracked state already consumed in the same render — packages/host/app/components/operator-mode/workspace-chooser/index.gts:306

The modifier's body ends in a bare synchronous measure(), which writes workspaceGridWidth/workspaceTileWidth/workspaceTileGap. But it's installed on the Your Workspaces list, which renders after the Favorites block — and Favorites passes @enlargedWidth={{this.favoritesTileWidthPx}}, whose getter chain reads workspaceTileWidth (the if (!this.workspaceTileWidth) return null early-return consumes the tag too). So for any user who already has a favorite when the chooser opens, the read happens first and the modifier writes into the same render transaction: Ember's backtracking-rerender assertion in dev builds. This is the same hazard documented for the onFocusIn path above — "Writing selectedIndex there trips Ember's backtracking-rerender assertion."

No test catches it: openChooserWithFavorite assigns workspaceFavorites after visitOperatorMode, because (per its own comment) login resets the matrix service and drops a pre-visit assignment. By then the modifier is installed, and with no arguments it never re-invokes — so measure() never runs in a transaction that reads favoritesTileWidthPx. That awkwardness is also why I couldn't build a repro harness; I verified the ordering by reading, not by observing the assertion. Manual check: favorite a workspace, reopen the chooser in a dev build, watch the console.

Scheduling the first measure() via next/scheduleOnce('afterRender') fixes it and costs one extra frame on open.

Robustness

3. A failed counts fetch never retries — packages/host/app/services/realm.ts:937

The catch logs and leaves the map untouched, so nothing trackFavoriteCounts depends on changes (same favoriteCountsKey, same indexCountsRevision) and the modifier doesn't re-run. One transient 500/offline blip — or a realm the server omitted because getIndexCounts() threw — would leave every favorite tile with a blank stats row for the session. The comment says "a later attempt retries"; I couldn't find the trigger.

4. getIndexCounts caches failures and doesn't dedupe concurrent callers — packages/runtime-common/realm.ts:7247

A queryIndexCounts() failure returns an all-null object, which is truthy, so it's cached until the next index swap — one DB hiccup means no stats until that realm re-indexes. And since only the resolved value is memoized rather than the promise, N concurrent /_federated-index-counts requests each run the full per-url aggregate. Caching the promise and skipping the null-triple would cover both.

5. Stale-marking races the first load — packages/host/app/services/realm.ts:893

markIndexCountsStale early-returns when indexCountsByRealm has no entry. If a realm finishes indexing while its first counts request is in flight, the mark is dropped and the in-flight response (computed pre-swap) is then stored as fresh. Marking inFlightIndexCounts members stale, or bumping the epoch unconditionally, would close it.

6. Only the batch route carries the new timestamps — packages/host/app/services/realm.ts:426

fetchInfoFromServer hits per-realm /_info, which this PR deliberately leaves on plain getRealmInfo(). Any realm loading through fetchInfo/refreshInfo rather than the boot-time /_federated-info batch — a workspace created mid-session, say — would have createdAt/updatedAt undefined, suppressing its footer and (for catalogs) sorting it to the bottom of sortByCreatedAtDesc. A reload masks it, which is what makes it easy to miss.

7. timestamp without time zone reinterpreted in the process TZ — packages/runtime-common/realm.ts:623

created_at/updated_at are timestamp (no tz) defaulted from now(). pg parses that as local time, so toISOStringOrNull shifts by the process's UTC offset whenever the realm-server's TZ differs from the DB session's. On a non-UTC box that reads as "Created 8 hrs ago", or lands in the future and clamps to "Updated just now". timestamptz, or an explicit AT TIME ZONE 'UTC' in the SELECT, would be sturdier.

UI / accessibility — needs a browser to confirm

8. Keyboard focus on the Options button is invisible — packages/host/app/components/operator-mode/workspace-chooser/workspace.gts:665

.tile-menu-btn gains opacity: 0, and the old :focus-within rule was replaced by :has([aria-expanded='true']). A keyboard user tabbing through a tile would land on a fully transparent focused button with no visible indication until they open the dropdown. Re-adding :focus-within { opacity: 1 } alongside the new rule should fix it.

9. .tile-status-bar may swallow tile clicks — packages/host/app/components/operator-mode/workspace-chooser/workspace.gts:708

It's a sibling of the ItemContainer button at position: absolute; z-index: 3 with default pointer-events (which its tooltips need). On an enlarged favorite tile that would make the hosted/visibility pill an inert strip across the top-left — clicking it does nothing instead of opening the workspace.

10. defaultSelectedIndex lands on "New Workspace" in the empty state — packages/host/app/components/operator-mode/workspace-chooser/index.gts:382

With no favorites and no user workspaces (new user, or everything archived/filtered), both branches fall through to return 0, which is addWorkspaceNavIndex, and focusWhenSelected focuses it — so the first Enter opens the create-workspace modal, the hazard the surrounding comment warns about. Falling back to catalogNavBase when catalogs exist would avoid it.

11. The top-bar center is now out of flow — packages/host/app/components/operator-mode/submode-layout.gts:678

Swapping flex: 1 for position: absolute; left: 50%; transform: translate(-50%, -50%) drops the flex guarantee that the center group can't collide with the left (workspace/search) and right (profile) groups. At narrow container widths it would overlap them and, as a normal pointer-events element higher in the stack, intercept clicks on the controls underneath.

🤖 Reviewed by Claude (Opus 5)

8 is confirmed. 11 is correct that there's overlap:

Follow-up on finding 2, on the shape of the fix — measureWorkspaceGrid can lose two of its three measurement triggers, which turns that finding into a deletion rather than an addition.

The window.addEventListener('resize', measure) is redundant. Anything that changes the viewport width also changes el.clientWidth, so the ResizeObserver already covers every case the window listener does. The reverse isn't true — the window listener misses a scrollbar appearing when the workspace list grows past the viewport height (narrows el, no resize event; adding a workspace or WorkspaceLoadingIndicator rendering can both do it), any surrounding panel changing width, and zoom/font-size changes, which are inconsistent about firing resize. The observer is the one worth keeping.

The trailing synchronous measure() is also redundant, and it's what trips the assertion. Per spec, observe() delivers an initial callback with the element's current size, and that callback lands after the render transaction commits rather than inside it. So dropping the bare measure() gets you the first measurement anyway and fixes finding 2 without needing an explicit next/scheduleOnce('afterRender') wrapper:

let ro;
if (typeof ResizeObserver !== 'undefined') {
  // observe() delivers an initial callback with the current size, so this
  // covers the first measurement too — and it lands after the render
  // transaction commits, which keeps the tracked writes out of it.
  ro = new ResizeObserver(measure);
  ro.observe(el);
}
return () => ro?.disconnect();

I checked the ResizeObserver-absent branch before suggesting this, since it's the obvious objection — and it degrades gracefully on its own: tilesPerRow returns 3, favoritesSlotWidth returns null, favoritesTileWidthPx returns undefined, and the tile falls back to its static CSS width. "Never measured" is already a supported state, so no else branch is needed to stay correct. (Which also raises the question of whether the typeof guard is needed at all — ResizeObserver has been baseline for years — but that's a judgement call about which render paths you expect this to run in.)

Preferring this over wrapping measure() in next/afterRender for two reasons: it leaves one measurement path instead of two doing identical work on open, and RO's before-paint delivery is strictly earlier than a next() macrotask. Neither approach can promise no single-frame flash of the static width, since the tracked write still routes through a backburner flush either way.

One caveat on provenance: the initial-callback behavior is from the spec, not something I re-confirmed in a browser here. The getter fallbacks above I did verify against the diff.

🤖 Reviewed by Claude (Opus 5)

[Claude Code 🤖] All eleven findings are addressed on the branch — findings 1–11 in e80d84e, with a follow-up in eaf8701 after finding 6's fix broke CI (details under 6). Per finding:

1. realm_registry.updated_at never moves for source realms — Confirmed and fixed in e80d84e. touchSourceRealmUpdatedAt() runs from both incremental-index invalidation hooks, so any write that indexes advances the timestamp — once per write batch, scoped to kind = 'source' (published rows keep publish-time semantics via last_published_at, bootstrap rows never change), and best-effort so a failed touch can't fail the index that triggered it. The ETag-rationale comment now names this mechanism instead of asserting a behavior that didn't exist.

2. Backtracking-rerender in measureWorkspaceGrid — Fixed in e80d84e, taking the deletion shape from your follow-up comment; replied there.

3. Failed counts fetch never retries — Fixed in e80d84e. A failed or partial response marks every requested realm stale and schedules one delayed wake that bumps the revision consumers already track, so their loaders refetch — a slow poll while the failure persists, self-stopping on success. The "a later attempt retries" comment now has an actual trigger behind it.

4. getIndexCounts caches failures and doesn't dedupe concurrent callers — Fixed in e80d84e in the shape you suggested: the in-flight promise is memoized so concurrent /_federated-index-counts callers share one aggregate, the all-null failure triple is never cached (the next request retries), and an index swap drops the in-flight promise too so an overlapping request can't repopulate the cache with pre-swap counts.

5. Stale-mark racing the first load — Fixed in e80d84e. markIndexCountsStale also marks realms in inFlightIndexCounts, and loadIndexCounts claims staleness when the fetch starts and re-checks it in finally, so a mid-flight index swap forces a refetch rather than letting the pre-swap response be stored as fresh.

6. Timestamps only on the batch route — Fixed in e80d84e: fetchInfoTask asks the federated batch for the single realm before falling back to the lean per-realm /_info, so a workspace created mid-session picks up its lifecycle timestamps. That call is also what turned every host CI shard red: at shard warm-boot it runs before matrix start() hands the client to RealmServerService, loginTask threw its no-client error before the finally that clears loggingIn, and every later login() — including the one start() makes right after setClient — awaited the stale rejected task instance and surfaced the error as an uncaught global failure. eaf8701 fixes both layers: loginTask now clears loggingIn on every exit (a pre-client attempt can no longer poison later logins), and prefetchRealmInfos no-ops until the matrix client exists — pre-login callers fall through to the lean per-realm fetch, while the post-login boot re-runs the batch for every available realm, so the mid-session-workspace case this finding is about (which only arises logged-in) still gets its timestamps.

7. timestamp without time zone reinterpreted in the process TZ — Confirmed and fixed in e80d84e. A migration widens created_at/updated_at to timestamptz, reinterpreting the existing wall-clock values as UTC (they were written by now() against a UTC session). It sits in the additive phase: the previously deployed revision neither reads these columns nor inserts anything now() can't satisfy in either type.

8. Invisible keyboard focus on the Options button — Thanks for confirming it in a browser; fixed in e80d84e with the :focus-within reveal you suggested, alongside the :has([aria-expanded='true']) open-state rule.

9. .tile-status-bar swallowing tile clicks — Fixed in e80d84e. The bar is pointer-events: none so clicks fall through to the tile's open-workspace button, and the two tooltip triggers re-enable pointer-events: auto on themselves so hovering the hosted/visibility icons still surfaces their tooltips.

10. Empty state lands selection on "New Workspace" — Fixed in e80d84e with the fallback you suggested: with no favorites and no user workspaces, selection prefers the first catalog when one renders, and only lands on index 0 when there is genuinely nothing else to land on.

11. Top-bar center out of flow — Confirmed by your screenshot; fixed in e80d84e. The center group is a flex: 1 flex child again, so the middle track is reserved between the workspace and profile controls — the portaled expanded-card-header pill can neither slide under them at narrow widths nor intercept their clicks, and it stays centered within the track via its own max-width/margin: auto.

CI is re-running on eaf8701.

[Claude Code 🤖] Adopted in e80d84e, in exactly this shape: the window resize listener and the trailing synchronous measure() are gone, and the ResizeObserver's initial post-commit callback is the sole first measurement — which is what keeps the tracked writes out of the render transaction that already read favoritesTileWidthPx. The one judgement call left as-is: the typeof ResizeObserver guard stays, since never-measured is a supported state (tilesPerRow falls back to 3 and the tile keeps its static CSS width), and the guard is where that contract is documented. The modifier's comment records both the initial-callback reliance and the resize-listener subsumption so neither gets reintroduced as a "fix".